Stage 3: Migration Process
Use these commands and scripts to complete the migration process.
If you are upgrading from
2019.x.x
run the following scripts. If not, go to Step 2.🛑 Later versions (2020.1.x and higher) do not require this first step.
JobsAndTasks
migration script# cd /opt/pronghorn/current/node_modules/@itential/app-workflow_engine # npm run migrate
JobsFrom20193
migration script⚠ This script aids in migrating any active running jobs between major versions for certain scenarios. If proper procedure is followed and all jobs are paused, canceled, or completed, this script is optional.
# cd /opt/pronghorn/current/node_modules/@itential/app-workflow_engine/migration_scripts # node migrateJobsFrom20193.js
normalizeGroups
script (2019.3 and higher)# cd /opt/pronghorn/current/node_modules/@itential/app-workflow_engine # npm run normalizeGroups
migration_scripts
under Configuration Manager⚠ This script upgrades all the old Golden Configs to Jinja2 Templates. If you have any Golden Configs at all and you are upgrading from
2019.x
to2020.2.x and higher
, then this script is required.# cd /opt/pronghorn/current/node_modules/@itential/app-configuration_manager/migration_scripts # node migrate_to_jinja.js
Run the following for Tags.
# cd /opt/pronghorn/current/node_modules/@itential/tags/migration_scripts # node migrateTagRefs.js
Audit (confirm) all Template Builder security dependencies (
chroot
,sudo
,ldd
) are installed and tested. These security dependencies are required for Template Builder to execute Jinja2 templates in a contained context.⚠ For more information, see Template Builder Dependencies in the IAP Installation guide.
Install the shell utilities.
yum -y install sudo chroot ldd
Verify the user that is used to run the server (usually
pronghorn
) is permitted to runsudo chroot
without a password prompt. An example command which accomplishes this is shown below, but the system admin is expected to tailor this command to their environment. As long as the server is permitted to runchroot
throughsudo
without a password prompt, Template Builder can sandbox Jinja2 template execution.echo "pronghorn ALL=(ALL) NOPASSWD: $(command -v chroot)" >> /etc/sudoers
Make sure Template Builder is permitted to copy in all dependencies required by Python. These dependencies are the output of the
ldd
command, as well as all paths in Python's internalsys.path
constant. If file permissions prevent Template Builder from copying these files into itschroot
jail directory, Python will not be able to execute within the sandbox subshell and Template Builder will execute in an insecure mode.Verify IAP is running and examine the logs.
Template Builder will report that it is creating a sandbox directory for Jinja2 template execution, and when it is finished, it will report either success or failure.
Once Template Builder has finished initializing the sandbox directory, run a Jinja2 template.
Examine the server logs and look to make sure there are no warnings stating that Jinja2 execution is running in an insecure mode.
Run index validation and confirm the latest indexing metrics.
Login to IAP and confirm you are able to view job details in the Active Jobs / Completed Jobs / Cancelled Jobs tabs from the Job Manager page.
⚠ If there are no job details and you get a Run Indexing Alert, resolve using the links below.
How To Fix Indexing For Target Release 2020.1.x / 2020.2.x Target Release 2021.1.x Figure 4: Job Manager Indexing Alert
Navigate to the Job Details page in IAP to update and migrate jobs.
This step uses a Just-in-Time (JIT)/ OnDemand migration strategy, which puts job migration into the
getJobDetails
API. This means whenever a user displays the Job Details page, job migration occurs only when needed.Confirm the Start Date, End Date and Assignee details are updated.
Figure 5: JIT OnDemand job Migration
Next Step
Go to Stage 4: Post-Migration to confirm all jobs have migrated.